寫在前面：
這個系列主要想記錄我自己研究及參與 EU Cyber Resilience Act（CRA）導入過程中的一些心得、觀察與個人解讀，也希望藉這 30 天和同樣關注 CRA、Product Security 的朋友交流。
CRA 畢竟是歐盟法規，因此文章內容僅代表我現階段的理解與看法，不代表主管機關或法規的正式解釋，也不代表文中提到的做法一定能被歐盟接受。相關要求仍應以 CRA 正式法規、European Commission 後續 Guidance、Harmonised Standards 及主管機關實務為準。。今天談的 Readiness Checklist 也不是 CRA 官方提供的檢核表，更不是用來判定某家公司「是否已經符合 CRA」的工具。
它比較像是我在參與 CRA 導入過程中，面對 Management 很實際的一個問題——「我們到底準備到什麼程度了？」——逐漸整理出來的一種專案管理方式。

Day 21 把 Roadmap 排出來之後，下一題很自然就是：「所以現在完成幾 %？」
上一篇談到，我會從 2026/9/11 的 Article 14 Reporting Obligations 與 2027/12/11 的 CRA 主要適用日期往回倒推，把 Article 14、Product Inventory、SSDLC、SBOM、Supplier Security、Technical Documentation 與 Conformity Assessment 分階段安排。
Roadmap 排出來之後，Management 很自然就會問：
「所以我們現在 CRA 到底完成幾 %？」
50%？70%？還是 90%？
但這題其實沒有想像中那麼容易回答。
假設規劃的 20 份 Procedure 已經完成 18 份，從文件完成率來看是 90%。可是如果 Product Risk Assessment 還沒真正開始、SBOM 還沒有辦法穩定產出、PSIRT 雖然有 SOP，但真的發生 Vulnerability 時大家還不知道誰負責判斷 Article 14，那真的可以說：
CRA 90% Ready 了嗎？
研究到這裡，我越來越覺得：
「文件完成度」跟「CRA Readiness」最好不要直接畫上等號。

一、重點應該是「這個 Capability 跑得起來嗎？」
以前做 Compliance，很自然會從 Document Checklist 開始：有沒有 Policy？有沒有 Procedure？有沒有 Record？這些當然都很重要。
但 CRA 比較特別的是，它牽涉的是整個 Product Lifecycle。
所以除了文件之外，我現在還會繼續往下問：Process 有沒有建立？Owner 是誰？需要的 Tool 或 Mechanism 有沒有準備？Product Team 實際做過了嗎？Evidence 留在哪裡？
最後甚至會問一個很簡單的問題：
如果明天真的發生事情，這套 Process 跑得起來嗎？
這可能比「文件完成幾 %」更接近我想知道的 Readiness。

二、第1個 Domain：Governance
我會先看 CRA 到底有沒有人負責。
例如 CRA Program Owner 是誰？Management Sponsor 是誰？Product Owner 知不知道自己在 CRA 裡的角色？R&D、Product Security、Legal、QA、Procurement、Product Compliance 等單位的 Responsibility Boundary 是否清楚？跨部門有爭議時由誰決定？Issue 又要 Escalate 到哪裡？
Day 20 談 RACI 時，我自己最大的感受就是：
CRA 如果只有 Security Team 知道，基本上很難真正運作。
即使所有 Procedure 都已經 Approved，但 Product Team 還認為「CRA 是資安部門的事情」，我自己還是不太敢把 Governance 打成 Ready。

三、第2個 Domain：Product Scope & Classification
接下來我會看公司到底知不知道：
哪些 Product 要處理。
例如哪些 Product 會進入 EU Market？哪些屬於 Product with Digital Elements？哪些經評估屬於 Out of Scope？哪些還需要 Further Assessment？In-scope Product 又屬於 Default、Important Class I、Important Class II，或其他需要進一步確認的 Category？
除了結果之外，我自己其實特別在意：
判斷依據有沒有留下來。
尤其是 Out of Scope。
「沒有放進 CRA 清單」跟「經過分析後，有理由判斷目前不在 Scope」，我覺得是完全不同的事情。
所以 Product Inventory 對我而言不只是一張產品名單，而是 CRA Scope Management 的基礎。

四、第3個 Domain：Cybersecurity Risk Management
再來就是 CRA 很核心的一塊：
Cybersecurity Risk Assessment。
我會看公司有沒有 Methodology，Product Team 知不知道怎麼執行，Product 的 Asset、Threat、Attack Surface 與 Risk 是否有被適當分析，以及分析出來的 Risk 能不能進一步連到 Security Requirement、Risk Treatment 與 Verification。
另外，Product Change 之後會不會重新檢視 Risk，也是我會關注的地方。這跟 Day 17 談的 Substantial Modification 其實也接得起來。
如果公司現在有一份很完整的 Risk Assessment Template，但還沒有任何 Product 真正使用過，我自己可能會把它評成：
Process Defined，但還不能直接說 Operationally Ready。

五、第4個 Domain：Secure Product Development
這一塊我們從 SSDLC 看。
例如 Security Requirement、Threat Modeling、Secure Design、Secure Coding、SAST、SCA、Security Verification、Release Security Review 等活動，有沒有真正進入 Product Development Lifecycle。
但我自己不會看到「公司已經買了 SAST Tool」就直接打一個綠色勾勾。
因為還要繼續問：哪些 Product 要掃？什麼時間點掃？Finding 誰負責處理？Release 前有哪些 Acceptance Criteria？Exception 怎麼處理？最後 Evidence 又保存在哪裡？
所以我自己很喜歡提醒：
Tool Deployment ≠ Capability Readiness。
Tool 是能力的一部分，但 Process、People、Criteria 與 Evidence 同樣重要。

六、第5個 Domain：SBOM & Component Management
SBOM 也是我會單獨拉出來看的 Domain。
最基本當然是能不能產出 SBOM，但我還會往下問：它能不能正確對應 Product Version？Component Version 是否準確？Third-party Component 與 Open Source 是否能被識別？Product 更新後 SBOM 會不會跟著更新？
更進一步，我自己很在意：
這份 SBOM 到底有沒有真的被使用？
例如能不能拿來支援 Vulnerability Monitoring？當某個 Third-party Component 爆出 CVE 時，能不能快速找出哪些 Product Version 受到影響？
如果 SBOM 產出後只是放進某個 Folder，從此沒有人再打開，我會覺得它比較像一個 Compliance Artifact，而還不是完整的 Product Security Capability。

七、第6個 Domain：Vulnerability Handling / PSIRT
這一塊對現在的 CRA 導入尤其重要。
因為 Article 14 的 Reporting Obligations 從 2026 年 9 月 11 日開始適用，所以我自己會把 Vulnerability Handling 與 PSIRT Readiness 放在很前面的 Priority。
我會確認 External Vulnerability 怎麼進來、Security Researcher 能不能找到聯絡方式、PSIRT 誰負責 Intake、Product Impact 誰分析、R&D 怎麼進來、Fix / Mitigation 誰負責，以及 Customer Communication 如何進行。
但最後我還是會再問：
真的跑過嗎？
如果只有一份 PSIRT Procedure，卻沒有實際 Case、Pilot 或 Exercise，我會認為已經建立了基礎，但距離真正 Ready 還有一段距離。

八、第7個 Domain：Article 14 Reporting
Article 14 我自己會暫時從一般 PSIRT Capability 中再單獨拉出來，主要是因為它的適用日期已經非常近。
Readiness 不能只是「我們有 Reporting SOP」，而是要進一步確認 Actively Exploited Vulnerability 與 Severe Incident 的判斷與 Escalation Mechanism、24 小時 Early Warning、72 小時 Notification 與後續 Reporting 怎麼執行。
另外還有很多 Operational Detail：誰有權限提交？ENISA Single Reporting Platform 的準備狀況如何？假日怎麼處理？海外 Product Team 如何通知？Legal、Management、Product Owner 什麼時間點介入？
這些如果沒有實際跑過，我自己很難只看 Procedure 就判斷 Ready。

九、Article 14，用 Scenario 來驗證看看
例如我可能直接丟一個情境：
星期五晚上 22:30，External Researcher 通知公司：Product X 存在 Vulnerability，而且有資訊顯示可能已被實際利用。
然後開始計時。
誰第一個收到？誰負責 Initial Triage？Product Owner 找得到嗎？R&D 能不能在合理時間內協助分析？Article 14 Assessment 由誰啟動？需要的 Product Information 與 Evidence 拿得到嗎？
這樣真的跑一次，我覺得很多平常藏在 Procedure 裡看不到的 Gap，可能十幾分鐘就會浮出來。
所以：
對 Operational Capability 而言，「演練過」通常比「文件寫完了」更能讓我知道現在到底 Ready 到什麼程度。

十、因此，嘗試開始用「成熟度」而不是只有紅黃綠來看
如果真的要做 Management Dashboard，我想嘗試將每個 Capability 粗略分成幾個階段：
Level 我自己的理解
Level 0 — Not Started 尚未開始
Level 1 — Designed Requirement、Process 或方法已經設計
Level 2 — Implemented Owner、Procedure、Tool / Mechanism 已建立
Level 3 — Operated 已經有 Product 或實際 Case 執行紀錄
Level 4 — Validated 已透過 Exercise、Audit、Review 等方式驗證
Level 5 — Improved 已根據執行結果進行改善
這當然不是 CRA 官方的 Maturity Model。
只是對我而言，它比單純 Red / Yellow / Green 更容易回答一個問題：
我們現在是「有設計」，還是「真的做過」？
這兩個狀態，在專案管理上其實差很多。

十一、第8個 Domain：Supplier & Third-party Component
再來我會看 Product Security Supply Chain。
例如 Product-critical Supplier 是否已識別？Third-party Component 有沒有適當的 Security Due Diligence？Supplier 發現 Vulnerability 時要不要通知？Security Fix Responsibility 是否清楚？Component Support / EOL / EOS 資訊能不能取得？SBOM 或其他 Component Information 能不能支援 Product Risk Analysis？
這也是我覺得 CRA 導入很容易跨出傳統 Vendor Security Assessment 的地方。
以前 Supplier Security 可能比較偏向問：
「你們公司有沒有 ISO 27001？」
但到了 Product Security，我更在意的可能是：
「你提供給我的這個 Component，未來發現 Vulnerability 時，我能不能及時知道？」
兩者其實不是完全相同的問題。

十二、第9個 Domain：Technical Documentation
Technical Documentation 的 Readiness，我還是會回到 Day 14 談的：
Evidence Chain。
我不只問有沒有 Technical Documentation Template，而會實際抽一個 Product，看 Product Description、Architecture、Risk Assessment、Annex I Mapping、Standards、Security Test Evidence、SBOM、Vulnerability Handling Evidence 與 Version Information 能不能彼此對得起來。
甚至可以做一個很簡單的測試：
「現在指定一個 Product Version，我們可以在合理時間內把相關 Evidence 找出來嗎？」
如果答案是可以，而且 Product、Version、Risk、Requirement、Test Result 之間能夠 Trace，我自己才會比較放心。
因為真正重要的不是「有一份 Technical Documentation」，而是：
它背後的 Evidence 能不能支撐當初的 Conformity 判斷。

十三、第10個 Domain：Conformity Assessment / CE
接下來我會確認 Product Classification 是否已經相對穩定、Conformity Assessment Route 是否已經開始規劃，以及 Harmonised Standards Strategy 是否有人持續追蹤。
如果某些 Product 可能需要 Third-party Conformity Assessment，我也會希望提早了解 NB Readiness、Scope 與 Lead Time，而不是等 Product 全部完成之後才開始處理。
EU Declaration of Conformity 與 CE Marking 也是一樣。
如果公司本來就有 CE Compliance Process，我自己比較傾向把 CRA 整合進既有 Product Compliance Framework，而不是讓 Security Team 自己另外發展一套完全獨立的 CE Process。
這也延續 Day 15、Day 16 的想法：
CRA 最後仍然要從 Product Security 接到 Product Compliance。

十四、第11個 Domain：Post-market & Support Period
產品完成 Conformity Assessment、DoC 與 CE Marking 之後，Readiness 還沒有結束。
我還會繼續看 Support Period 有沒有定義、Vulnerability Monitoring 誰負責、Security Update 怎麼 Release、Customer 如何取得 Update、EOL 怎麼管理，以及 Product Change 發生時有沒有適當的 Cybersecurity Impact Assessment。
另外，Product 上市後如果收到 Vulnerability Report、Customer Security Question 或主管機關相關要求，內部有沒有明確的處理與 Escalation Path，也是我會關注的地方。
所以：
Post-market Capability 跟 Pre-market Compliance，對 CRA 都很重要。
這也是為什麼我一直覺得 CRA 很難被當成一次性的 Certification Project。

十五、最後還會加一個 Domain：Evidence & Auditability
這一項其實不是獨立的一條 CRA Requirement，而是我自己在做 Compliance Program 時很在意的管理觀念。
每一個 CRA Process，我都會再問一次：
Evidence 是什麼？
Risk Assessment 有 Assessment Record；SBOM 有 Versioned SBOM；SSDLC 有 Review、Scan、Test Result；Supplier Security 有 Assessment、Contract 或相關紀錄；PSIRT 有 Case Record；Article 14 有 Assessment、Decision 與 Reporting Record；Product Change 則有 Cybersecurity Impact / Substantial Modification Assessment。
因為 Process 即使真的做了，如果沒有留下適當紀錄，過了一段時間後還是很難回答：
「當初為什麼這樣判斷？」
所以我自己會把 Evidence Management 視為橫跨所有 CRA Workstream 的一條線。

十六、最後，這個 CRA Readiness Dashboard 可能會長這樣
假設今天只是拿來做 Management Review，我可能不會直接給一個「CRA 73% Completed」，而會先呈現不同 Domain 的成熟度。
例如：
Domain Design Implement Operate Validate
Governance ✓ ✓ ✓ △
Product Classification ✓ ✓ △ △
Risk Assessment ✓ △ △ —
SSDLC ✓ ✓ △ △
SBOM ✓ △ △ —
PSIRT ✓ ✓ ✓ ✓
Article 14 ✓ ✓ △ △
Supplier Security ✓ △ — —
Technical Documentation ✓ △ — —
Conformity Assessment △ — — —
Post-market ✓ △ △ —
這張表只是示意，不是 CRA 官方要求的 Dashboard。
但對我來說，它比：
CRA Overall Progress = 73%
更有管理價值。
因為 Management 一眼看到的不是一個看起來很精準的百分比，而是：
真正的 Gap 到底在哪裡。

十七、如果 Management 一定要一個百分比呢？
實務上，我也知道 Percentage 有時候避免不了。
Management Dashboard、Steering Committee、Project Review，最後還是很可能需要一個 Overall Progress。
但我自己會避免直接用：
完成文件數 ÷ 預計文件數。
因為 10 份文件完成 8 份，不一定代表 CRA 80% Ready。
如果真的要做，我可能會考慮 Domain Weighting + Maturity Score，而且權重不一定永遠固定。
例如現在 Article 14 Reporting 的適用日期已經很近，那它在 2026 年的 Priority 自然可能比較高；其他全面適用前仍有較長建置時間的 Capability，現階段則可能處在不同成熟度目標。
換句話說，我自己希望 Readiness Score 至少能反映：
Risk + Deadline + Capability
而不只是：
Document Count。

十八、最不想看到的是：「Dashboard 全綠，但沒有人真的跑過」
這可能是我自己做 Compliance Program 時最在意的一種情況。
Dashboard 全部 Green、Procedure 全部 Approved、Training Completion 100%，看起來非常漂亮。
結果真的收到 Vulnerability Report 時，第一句是：
「請問誰是 PSIRT？」
接著有人問：
「Article 14 是誰判斷？」
再下一句：
「Product Owner 今天休假。」
最後才發現：
「SBOM 好像在前一位 Engineer 的電腦裡。」
這時候，原本的 Green Dashboard 就沒有太大意義了。
所以做到現在，我自己越來越喜歡的是：
Evidence-based Readiness + Scenario-based Validation。
也就是不只問「有沒有」，還要問：
做過沒有？證據在哪？真的發生時跑不跑得起來？

Day 22 小結｜「完成幾 %」? 重點是「明天真的發生，跑得起來嗎？」
研究到 Day 22，我自己對 CRA Readiness 最大的心得是：
Readiness 不等於文件完成率。
對我而言，一個 Capability 從 Requirement 被理解，到 Process 被設計、Owner 被指定、Tool / Mechanism 建立，再到 Product 實際執行、Evidence 留存，最後透過 Exercise、Audit 或 Review 驗證並持續改善，這整條路走過之後，我才比較願意說：
這個 Capability 開始 Ready 了。
尤其現在距離 2026/9/11 Article 14 Reporting Obligations 已經非常近。
所以如果今天要我看 CRA Dashboard，我第一個想看的可能不是 Technical Documentation 完成幾份，而是：
明天真的收到一個可能涉及 Actively Exploited Vulnerability 的通報，我們能不能在要求的時間內把 Assessment、Escalation、Decision 與 Reporting Mechanism 跑起來？
如果可以，而且相關角色知道自己該做什麼、需要的資訊找得到、Decision 與 Evidence 也留得下來，對我而言，這比多完成幾份 Procedure 更接近真正的 CRA Readiness。
以上仍然只是我目前研究及參與 CRA 導入後的個人心得、解讀與看法，希望拿出來和大家交流。
CRA 並沒有規定企業一定要採用本文所提的 Domain、Maturity Level 或 Dashboard。這些比較像是我自己嘗試把 CRA Requirement 轉換成企業可以追蹤、管理與持續改善的一種方式。

Day 23 預告｜CRA 從 Project 變成日常後，我們到底要看哪些 KPI / KRI？
Day 22 解決的是：
「我們現在 Ready 到什麼程度？」
但如果 CRA 最後真的像前面幾天談的，逐漸從一個 Implementation Project 變成公司的 Product Security Operating Model，下一個問題就會出現：
怎麼知道這套機制半年、一年之後還是有效的？
難道每個月重新跑一次幾百題 Checklist？
我自己開始思考，也許可以把部分 CRA Capability 轉成日常 Management Metrics，例如 Product Classification Coverage、Risk Assessment Coverage、SBOM Coverage、Vulnerability Handling Timeliness、Article 14 Reporting Readiness、Supplier Security Coverage、Technical Documentation Completeness 等。
但這裡又有另一個很容易掉進去的陷阱：
KPI 100%，真的代表 Product Security 做得好嗎？
如果所有 Vulnerability 都在 SLA 內 Close，但大部分其實是 Risk Acceptance；如果 SBOM Coverage 是 100%，但 Component Version 根本不準；如果 Risk Assessment Completion 是 100%，但每一份內容都幾乎一樣，那這些漂亮的 KPI 到底代表什麼？
Day 23，我們就來聊我自己會怎麼思考 CRA 的 KPI / KRI，以及如何避免最後做出一張「數字全部很好看，但看不出 Product Security 到底有沒有真的運作」的 Management Dashboard。